fix: bumped @opentelemetry/instrumentation-tedious from 0.28.0 to 0.40.0 - #2679
fix: bumped @opentelemetry/instrumentation-tedious from 0.28.0 to 0.40.0#2679abhilash-sivan wants to merge 9 commits into
Conversation
6dafe24 to
b5cbce4
Compare
| expect(span.data.tags['db.user']).to.eql('admin@instana@nodejs-team-db-server'); | ||
| expect(span.data.tags['db.statement']).to.eql(expectedStatement); | ||
| expect(span.data.tags['net.peer.name']).to.eql('nodejs-team-db-server.database.windows.net'); | ||
| expect(span.data.tags['db.system.name']).to.eql('microsoft.sql_server'); |
There was a problem hiding this comment.
changed assertions to adapt new semconv
The stable OpenTelemetry semantic conventions (v1.33.0+) are supported starting with @opentelemetry/instrumentation-tedious v0.39.0. See the Semantic Conventions section
|
The problem is that Otel with ESM requires users to manually register the IITM hook. See: That means, our If we just update IITM in core with v3, we can still run into issues with Otel instrumentations who use an older instrumentations dependency. But the Otel ecosystem suffers from the same problem. As soon as you have one Otel instrumentation which is still on the old instrumentation version, it won't work for the customer OR the instrumentation dependency got already deduped to the root (which is for example not the case for our setup - its still on 207). Right now with the Tedious 0.40 update, all our Otel dependencies use the newer instrumentation dependency already. As soon the customer has any slightly different installation tree and IITM v2 is on the root, the Otel instrumentations would no longer work because the Otel instrumentation dependency loads IITM as a dependency and would load v2 from the root. But we instantiate v3. Similar to our setup: as soon as we have an Otel instrumentation which needs IITM v2, it does not work anymore. Can you please add proper explanations & tests which break the solution? The test can just be a simple reproduce script. For now we can only update to v3 + ^. Long-term: we may need to figure out if multiple IITM versions are being used (similar to the Otel API fix) |
2 participants
refs https://jsw.ibm.com/browse/INSTA-97288
Summary
Reason
@opentelemetry/instrumentation-tedious@0.40.0 depends on a newer @opentelemetry/instrumentation version that requires import-in-the-middle@^3. Keeping import-in-the-middle@2.x caused npm to install multiple IITM versions, which broke ESM module interception and prevented Tedious instrumentation from patching correctly.
Fix
Pinned import-in-the-middle to 3.3.2, ensuring all instrumentation uses a single shared IITM instance, restoring ESM tracing while remaining compatible with the updated OpenTelemetry instrumentation.
PR body